Gateway Load BalancerとPalo Alto VM-Seriesを利用した透過型侵入防御の実装をやってみた

Gateway Load Balancerの詳細の理解や実際の動作確認のためにPalo Alto NetworksのVM-Seriesと組み合わせて侵入防御をやってみました。百聞は一見にしかず、手を動かしやすいように丁寧に解説します。

#AWS Gateway Load Balancer

#Palo Alto Networks

#Elastic Load Balancing (ELB)

#AWS

臼田佳祐

2021.03.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

みなさん、侵入防御してますか？(挨拶

先日実装されたセキュリティ製品をいい感じに実装できるGateway Load Balancer(以下GWLB)とPalo Alto Networksの次世代ファイアウォールVM-Seriesを連携して透過型の侵入防御を実装してみました。

GWLBを利用することで各種ネットワーク型のセキュリティ製品について簡単に展開・高いスケーラビリティの確保・高可用性の実現が可能となります。

AWSのリリース: Introducing AWS Gateway Load Balancer – Easy Deployment, Scalability, and High Availability for Partner Appliances | AWS News Blog

Palo Altoリリース: How VM-Series Integrates with AWS Gateway Load Balancer - Palo Alto Networks Blog

ただ、新しい仕組み/概念なので公式リリースや各ベンダーからのリリースを読んでも、私はよく理解できませんでした。

というわけで、そのあたりも実装しながら把握したので、私なりにわかりやすく解説していきます。

今回はAWSとPalo Alto VM-Seriesについてある程度の理解が必要になることから、どちらかの知識が少なくても作業が行えるように説明や手順を少し手厚めに書いていきます。だいぶ長い記事になったので、知っているところは適宜読み飛ばしてください。

構築環境とGWLBの特徴

構築する環境はこんな感じです。

まずこの構成図を元に、Gateway Load Balancer(以下GWLB)の特徴と理解すべき事項について解説します。

じっくり語りますが、多分必要だと思うのでご容赦を。

GWLB特徴

GWLBはELBシリーズとして既存にあるALB/NLBと同じ箇所で設定するコンポーネントですが、役割は大きく異なります。既存のELBシリーズは提供するアプリケーションのフロントに設置しアプリケーションへのトラフィックをロードバランシングするためのサービスですが、GWLBはアプリケーションではなくネットワーク型のセキュリティ製品(IDS/IPSなど)をロードバランシングするためのサービスです。

しかしロードバランシングするだけならALB/NLBを利用することでも実現可能です。それでもGWLBを利用するのは他にもメリットがあります。

GWLBのトラフィックは直接GWLBが受け取りません。代わりにGWLB Endpoint(以下GWLBE)が受け取りトンネリングプロトコルGeneveを利用してパケットを中継します。この方式によりアプリケーションVPCの経路に透過的にセキュリティ製品を挿入することが可能です。

ここでBefore / Afterを見てみましょう。以下はPalo Alto Networks社資料のGWLB登場以前の構成です。左上が入り口でALB配下にVM-Seriesを配置しています。この構成ではスケーリングを維持するためIn/OutそれぞれNATが必要でした。また、VPC間の通信や内部からのアウトバウンドなどに利用するVM-Seriesが別で必要でした。

以下がAfterです。GWLBは各アプリケーションVPCにGWLBEを設置することでNATすることなく、トラフィックを受け付けてGWLBまでトンネリングします。GWLBからVM-SeriesへのトラフィックはGeneveプロトコルでラッピングされたまま、つまりアプリケーションVPCで受け取った状態のまま渡され検査され、通信が許可されればそのまま戻されます。NATをしない上透過的に挟めるためシンプルにセキュリティを挿入できるメリットがあります。

アプリケーションのルーティング

GWLBEにより透過的にアプリケーションにセキュリティを組み込めるシンプルさと引き換えに、その仕組を作るにはルーティングに少し手を入れる必要があります。

以下の要素について理解する必要があります。

VPC Ingress Routing
EndpointとAZ
ALBのSecurity Group

まずVPC Ingress Routingです。これは従来のサブネットに割り当てるルーティングテーブルではなく、IGWなどに割り当てることができるルーティングテーブルです。これにより外部から入ってくるトラフィックを特定のインスタンスやインターフェイスに曲げることが可能です。これにより、IGWから入ってくるALB宛のトラフィックをGWLBEへ送ることが可能です。曲げるという表現の通り、パケットには手を加えないで渡されます。実際にVPC Flow Logsで確認すると以下のような感じになっています。

5 999999999999 - [Source IP] [GWLBE IP] 57796 22 6 10 640 1615275294 1615275298 ACCEPT OK vpc-0c4aeebb16bd14d04 subnet-084ce4c4db2539f08 ap-northeast-1 eni-0a34a5208c7de0578 apne1-az1 - - IPv4 2 - - - [Source IP] [ALB IP] ingress

前半の[Source IP] [GWLBE IP]はVPCとしての送信元/送信先ですが、末尾の[Source IP] [ALB IP]は追加されたカスタムフィールドのpkt-srcaddrとpkt-dstaddrです。宛先が曲げられていることがわかります。

VPC Ingress Routingについては以下がわかりやすく説明しています。

GWLBEはエンドポイントです。インターフェイスは単体で作成されAZに依存しています。そのためマルチAZで利用するためにはAZの分だけサブネットとインターフェイスを作成しルーティングする必要があります。以下に詳細なルートテーブルも含めた図を載せます。

GWLBEが所属するサブネットとALBが所属するサブネットはルーティングが変わるのでサブネットを分ける必要があります。そして3つのコンポーネントでそれぞれ以下のルーティングを設定します。

IGW

IGWのルーティングはALBの各サブネット宛の通信をGWLBEに送ります。マルチAZなので各サブネットのAZにあるGWLBEを指定します。

GWLBEのサブネット

localのルーティングと外部向け通信をIGW宛に指定します。これはAZで違わないので同じものが利用可能です。ここはIGWからのトラフィックが直接入ってくるためパブリックサブネットと言えますが、GWLBEはパブリックIPを持たず、このサブネットにパブリックIPを持つリソースはありません。

ALBのサブネット

サービスの戻りの通信を直接IGWではなくGWLBEに向ける必要があります。つまり各サブネットでそれぞれのGWLBEを指定します。GWLBEは外部からアクセスする対象にならないためALBがパブリックIPを持ちます。パブリックIPを持つリソースがあるのでパブリックサブネットと言えますが、直接IGWに出ることはありません。このあべこべ感が面白いですね。

あとはこの構成を受けるALBのSecurity Groupの設定です。ALBが受け取るパケットはGWLBEを経由していますが、パケット自体は捻じ曲げた影響を受けていません。パケット内のSoruceとDestinationは変わっていません。というわけでALBのSecurity GroupはGWLBEが無いのと同じように設定する必要があります。一般向けサービスなら0.0.0.0/0で受け入れる必要があります。

GWLBのルーティング

GWLB側のルーティングは単純です。構成要素はGWLBとセキュリティ製品ですが、これはGeneveで通信をしています。GWLBはSecurity Groupを持たないのでGWLBのサブネットのアドレス帯からのアクセスをセキュリティ製品側のSecurity Groupで、UDP: 6081(Geneve)を許可します。

ここまででGWLBを活用した環境を構築する知識の整理ができました。ではやってみましょう。

やってみた

改めて今回の構成です。Palo Alto NetworksのVM-SeriesをGWLB配下で冗長化して活用することも出来ますが、もう少し検討する必要があるので今回はシングル構成でとどめておきます。VM-Series自体のメンテナンスのためにパブリックサブネットに設置してSecurity Groupのみで管理アクセスを守ります。

アプリケーション側はアプリケーションのインスタンスが外部にアクセスするためにNAT GatewayもALBと同じサブネットに設置します。

Secure VPC構築

まずはVM-Seriesの環境から作っていきます。以下のパラメータを使います。

VPC
- secure-vpc: 10.0.0.0/16
サブネット
- secure-public-subnet-a: 10.0.10.0/24
- secure-public-subnet-c: 10.0.20.0/24
IGW
- secure-igw
ルートテーブル
- secure-public-rtb: 0.0.0.0/0 IGW
セキュリティグループ
- secure-palo-sg:
  - UDP 6081 10.0.0.0/16
  - HTTPS 443 マイIP
  - SSH 22 マイIP

まずはVPCから。細かく手順を書いていきますのでわかってるよって人は次へ進んでください。

マネジメントコンソールからVPCの画面にアクセスします。まず左カラムのVPCから「VPCを作成」します。

名前とCIDRを入れて作成します。

続いてサブネットを作成します。左カラムサブネットから「サブネットを作成」します。

先ほど作成したVPCを選択します。

サブネット1つ目について入力して、新しいサブネットを追加します。

2つ目のサブネットも入力して「サブネットを作成」します。

インターネットゲートウェイを作成していきます。左カラムからインターネットゲートウェイの画面を開き、作成していきます。

名前を入れて「インターネットゲートウェイの作成」をします。

作成したらリソースの詳細画面で、右上のアクションから「VPCにアタッチ」していきます。

先ほど作成したVPCが選択しに出てくるので、これを選択して「インターネットゲートウェイのアタッチ」をします。

ルートテーブルを作成します。左カラムからルートテーブルを開いてルートテーブルの作成をします。

名前とVPCを入れて「作成」します。

作成したらルートを追加します。ルートテーブルを選択した状態で下画面「ルート」タブから「ルートの編集」を押します。

デフォルトで入っているlocalのルート以外に、新たにIGW宛の通信を入力して「ルートの保存」をします。

続いてルートテーブルをサブネットに割り当てます。ルートテーブルを選択したまま「サブネットの関連付け」タブから「サブネットの関連付けの編集」を押します。

作成した2つのサブネットを選択して「保存」します。

セキュリティグループを作ります。左カラムセキュリティグループを開いて「セキュリティグループを作成」していきます。

セキュリティグループ名と、説明も必須になるのでセキュリティグループ名を入れておいて、VPCを選択します。インバウンドにルールを追加して「セキュリティグループを作成」します。

以上でネットワーク周りは作成完了です。

VM-Series構築

AWS MarketplaceにあるPalo Alto NetworksのVM-Seriesをイメージを使ってEC2を作成します。

MarketplaceのVM-Seriesはいくつか種類があります。ライセンスの購入方法の違いとしてBYOL(ライセンス持ち込み)とPAYG(従量課金)、機能の違いでBandle 1/2があります。Bandle1はIDS/IPSなどの主に外部向けサービスを保護する機能、Bandle2には1に追加して内部のリソースを保護するためのURLフィルタリングやDNSセキュリティなどが含まれています。今回は侵入防御を使うことが目的なのでBandle 1で十分なのでこれを利用します。一時的な利用なので15日の無料トライアルができるPAYGのものを使います。加えてGWLBを利用するにはVM-SeriesのOSであるPAN-OSの10.0.2移行が必要となります。詳細な要件はこちらです。

まずこのイメージを利用するためにMarketplaceでサブスクライブしていきます。VM-Series Next-Generation Firewall Bundle 1を開いてContinue to Subscribeします。

Subscribeするために規約への同意が求められます。次の画面でAccept Teamsを押します。

同意したら、インスタンスの作成画面から作成していきます。AWSマネジメントコンソールでEC2のページにアクセスし、左カラムからインスタンスを開いて「インスタンスを起動」します。

AMIの選択画面では検索欄に「VM-Series」を入れ、「AWS Marketplace」欄からVM-Series Next-Generation Firewall Bundle 1のAMIを「選択」します。

確認画面が出てくるので「Continue」します。

インスタンスタイプはとりあえずなのでm5.largeを選択します。求められる要件はこちらにありますので、実際に利用する場合はこちらを考慮してください。

VPCとサブネットを先ほど作成したSecure VPCのものを指定します。パブリックIP割り当ては(いちおう)有効にしておきます。

今回はデータトラフィックを受けるインターフェイスと管理アクセスのインターフェイスで2つNICを利用するため、下の方のネットワークインターフェイス欄で「デバイスの追加」をします。

eth1が追加されたのを確認しつつ更に下の高度な詳細のユーザーデータにGWLBで利用する以下の設定を入力します。パラメータについてはこちらが参考になります。入力したら次へ。

mgmt-interface-swap=enable
plugin-op-commands=aws-gwlb-inspect:enable

ストレージはデフォルトのまま次の画面へ進めます。タグ画面でNameタグを適当に設定して次へ進みます。

セキュリティグループは先程作成したので、「既存のセキュリティグループを選択する」を選び作成したセキュリティグループを選択して次へ進みます。

そのまま進めて作成します。作成を完了したら、今回は管理アクセスをするため、eth1にEIPを割り当てます。まずはeth1のインターフェイスIDを確認します。

作成したEC2インスタンスを選択して、下部の設定一覧で「ネットワーキング」タグを開き下の方にスクロールします。ネットワークインターフェイスが2つあり、説明欄に「Primary network interface」と書かれていない方のインターフェイスIDを控えます。こちらが管理用です。

EIPを作成します。左カラムから「Elastic IP」を開き「Elastic IPアドレスの割り当て」をします。

そのままの状態で「割り当て」します。

割り当てたEIPをインターフェイスに関連付けします。「アクション -> Elastic IPアドレスの関連付け」を押します。

「ネットワークインターフェイス」を選択して、先程のインターフェイスIDを指定してプライベートIPアドレスに候補が1つあるのでそちらも選択して「関連付ける」します。

これで管理アクセスできるようになります。設定の大部分はWebの管理画面から行いますが、ログインのパスワードのみSSHでアクセスしCLIで設定します。アクセスするユーザーはadminで、sshコマンドだと以下のようになります。

ssh -i <private_key.pem> admin@<public-ip_address>

アクセスしたらconfigureコマンドで編集モードに入りset mgt-config users admin passwordでパスワードを設定します。なお、パスワード規則があるので注意します。以下に履歴を貼っておきます。

% ssh -i ~/.ssh/xxxxxxx.pem admin@xxx.xxx.xxx.xxx
The authenticity of host 'xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)' can't be established.
RSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'xxx.xxx.xxx.xxx' (RSA) to the list of known hosts.
Welcome admin.
admin@PA-VM> configure
Entering configuration mode
[edit]
admin@PA-VM# set mgt-config users admin password
Enter password   :
Confirm password :

[edit]
admin@PA-VM#

パスワードを設定したらブラウザからアクセスします。IPアドレス直接でhttpsでアクセスした場合、警告が出ますが無視してアクセスします。

ログイン画面でadminと先ほど設定したパスワードでログインします。

インターフェイスとその周辺の設定を行います。「NETWORK -> インターフェイス」を開いてethernet1/1のリンクを押して設定画面を開きます。インターフェイスタイプを「レイヤー3」にし、「設定」タブを開きます。仮想ルーターをdefault、セキュリティゾーンは「新規ゾーン」を選んでゾーンを作成していきます。

ゾーンはアクセス制御などに利用するグループのようなものです。複数のゾーンを定義してゾーン間でのアクセスのルールを指定したりできます。今回はapp-zoneという名前で1つのゾーンを作成して「OK」を押してethernet1/1に割り当てます。

ゾーンを設定したらインターフェイスの設定に戻り「IPv4」タブを開いてタイプ「DHCPクライアント」を選択して「OK」を押します。これによりAWSが割り当てているIPが割り当たります。

設定はコミットするまで割り当たりません。右上の「Commit」を選んで「コミット」を押します。

しばらくしたら完了します。閉じておきます。

正常に設定できていれば、インターフェイスのリンクが緑になり正常に設定できたことが確認できます。

基本的な設定は一旦終わりです。また後でGWLBEを作成したあとに追加で設定します。

Workload VPC構築

アプリケーション側の環境を作っていきます。今回はIPが重複しても大丈夫なことを確認するため、あえてSecure VPCと同じCIDRを設定してみます。

VPC
- workload-vpc: 10.0.0.0/16
サブネット
- workload-gwlb-subnet-a: 10.0.210.0/24
- workload-gwlb-subnet-c: 10.0.220.0/24
- workload-public-subnet-a: 10.0.10.0/24
- workload-public-subnet-c: 10.0.20.0/24
- workload-private-subnet-a: 10.0.110.0/24
- workload-private-subnet-c: 10.0.120.0/24
IGW
- workload-igw
NGW
- workload-ngw-a
- workload-ngw-c
ルートテーブル
- workload-igw-rtb:
  - 10.0.10.0/24 GWLBE a
  - 10.0.20.0/24 GWLBE c
- workload-gwlb-rtb:
  - 0.0.0.0/0 IGW
- workload-public-rtb-a:
  - 0.0.0.0/0 GWLBE a
- workload-public-rtb-c:
  - 0.0.0.0/0 GWLBE c
- workload-private-rtb-a:
  - 0.0.0.0/0 NGW a
- workload-private-rtb-c:
  - 0.0.0.0/0 NGW c
セキュリティグループ
- workload-alb-sg:
  - HTTP 80 マイIP
- workload-web-sg:
  - HTTP 80 workload-alb-sg

Secure VPCで説明した設定と同じ部分は割愛します。GWLBEとNGWを設定するルートテーブルのルート設定やIGWへのアタッチは後回しします。

VPC/サブネット/IGW/ルートテーブル/セキュリティグループを作成したらNGWを作成していきます。

VPCのマネジメントコンソール画面で左カラムからNATゲートウェイを開いて「NATゲートウェイを作成」します。

名前とサブネットを適切に入力し「Elastic IPの割り当て」を押して割り当て、「NATゲートウェイを作成」します。これをAZ毎に作成します。

GWLB構築

本命のGWLBを作成していきます。EC2のマネジメントコンソール左カラムのロードバランサーを開いて「ロードバランサーの作成」をします。

Gateway Load Balancerの「作成」を押します。

適当な名前(今回は「palo-gwlb」)を入れPalo Alto Networks VM-Seriesを設置した方のVPCを選択します。2つ作ったので間違えないように。AZを2つとも選択して次に進みます。

VM-Seriesのインスタンスを含むターゲットグループを作成します。「新しいターゲットグループ」のまま適当な名前(今回は「palo-tg」)を入れて次へ進みます。

下の方のインスタンス一覧から先ほど作成したVM-Seriesのインスタンスを指定して「登録済みに追加」をします。情報の「登録済みターゲット」欄に追加されたら次へ。確認して作成を完了します。

作成できたら、マルチAZで可用性を確保するためにクロスゾーン負荷分散を有効化します。ロードバランサー詳細画面下部にある「属性の編集」を押します。

クロスゾーン負荷分散を「有効化」して「保存」します。

GWLBが作成できたので、トラフィックを送るためのGWLBEも作成します。エンドポイントを作成する前に、GWLB側にエンドポイントサービスを作成する必要があります。

VPCマネジメントコンソール左カラムのエンドポイントのサービスを開き「エンドポイントサービスの作成」をします。

作成したGWLBを選択し、「サービスの作成」をします。

作成できたらエンドポイントサービスの詳細画面から、サービス名を控えておきます。エンドポイントの作成に必要になります。

続いてエンドポイントの作成です。引き続きVPCマネジメントコンソール左カラムのエンドポイントを開き「エンドポイントの作成」をします。

サービスカテゴリで「サービスを名前で検索」を選び先程控えたエンドポイントサービス名を入力し「検証」します。サービス名が見つかったらGWLBEを作成する(Workload側)VPCとサブネットを選択します。なお、エンドポイントの作成は現状1つずつしかできないので、この作業を2回行いAZ毎にGWLBEを作成します。

2つとも作成したら、エンドポイントサービス側でこれを承認します。エンドポイントサービスの詳細画面に戻り「エンドポイント接続」タブからエンドポイントを選択し「アクション -> エンドポイント接続リクエストの承認」を2つとも実施します。しばらくすると状態が使用可能に変わります。

GWLBEを作成したら、ルーティングにこれを組み込みます。ついでに先程説明していない他のルーティング設定も行います。

IGWにアタッチするVPC Ingress Routing用のworkload-igw-rtbの詳細画面を開き「Edge Associations」タブから「Edit edge associations」を押します。

IGWを選択して「Save」します。

IGW用のルートテーブルにGWLBEを追加します。AZ毎にGWLBEが違うので、注意します。

他のGWLBEやNGWが必要なルートテーブルもすべて設定し、各サブネットにアタッチしておきます。

VM-SeriesにGWLBEをアソシエイト

作成したGWLBEとVM-Seriesのインターフェイスを関連付けします。まずはアタッチ先のVM-Seriesの仮想インターフェイスを作成します。先程設定したインターフェイスのページにアクセスします。ethernet1/1はVM-Seriesから見ると物理的なインターフェイス(実際にはEC2によって提供される仮想的なインターフェイスですが)ですが、VM-Seriesとしてそのインターフェイス内に仮想インターフェイスを作成可能です。この仮想インターフェイスとGWLBEを関連付けることが可能です。

ethernet1/1がハイライトされている状態で画面下部の「サブインターフェイスの追加」を押します。

サブインターフェイスの番号を適当に、タグも(実際には使われないので)適当に入力し、設定タブにて仮想ルーターとセキュリティゾーンを適当に設定します。もし複数のアプリケーションを管理する場合にはセキュリティゾーンは個別に作成したほうがいいです。

IPv4タブに切り替えてDHCPクライアントに切り替えて「OK」します。

設定した内容をコミットします。

コミットしたら仮想インターフェイスが作成完了します。

GWLBEを関連付けします。VM-Series上ではGWLB関連の機能はプラグインとなっていて、CLIからの変更になります。SSHで再びアクセスして以下のコマンドを実行します。コマンドの詳細はこちら。

request plugins vm_series aws gwlb associate vpc-endpoint <vpce-id> interface <subinterface>

エンドポイントが2つあるので、どちらもethernet1/1.1に関連付けます。以下のコマンドで正常にアソシエイトできているか確認できます。

admin@PA-VM> show plugins vm_series aws gwlb

    GWLB enabled    :    True
    Overlay Routing :    False
    ================================================
    VPC endpoint              Interface
    ================================================
    vpce-0a44c418c91cbbf3     ethernet1/1.1
    vpce-08d664e37169c4e8     ethernet1/1.1

ポリシー設定

インターフェイスの設定が完了しましたが、デフォルトのままでは通信が許可されません。明示的に許可する設定が必要で、これをセキュリティポリシーといいます。

「POLICIES -> セキュリティ」を開き画面下部の「追加」を押します。

名前を適当に(今回は「app-zone-policy」)入力します。

「送信元」タブで送信元ゾーンを「追加」から「app-zone」を選択します。

「宛先」タブで宛先ゾーンも「追加」から「app-zone」を選択します。追加情報ですが、通常の利用方法の場合、インターフェイスから別のインターフェイスへ通信が通るためゾーンをまたがるのですが、GWLBの場合には同じインターフェイスで出入りするため、送信元と宛先のゾーンが一緒になります。詳細に制御していく場合は、セキュリティポリシーの中でアドレスやプロトコルなども指定していく必要があります。

「アクション」タブでアクションが「Allow」であることを(念の為)確認して「OK」します。

ポリシーを設定したら右上からコミットします。

ALB-Web構築

Workload VPCにALBやWeb用のEC2を構築していきます。EC2の前に、EC2で利用するIAM Roleを作成します。今回Web用EC2にはSSHの接続経路を確保しておらず、代わりにAWS Systems Manager Session Managerでシェルアクセスするため、SSMの権限を持つIAM RoleをEC2にアタッチする必要があります。

IAMのマネジメントコンソールを開き左カラムのロールから「ロールの作成」を始めます。

信頼されたエンティティは「AWSサービス」のまま、ユースケースの選択で「EC2」を選択して進めます。

アタッチするIAMポリシーはAmazonSSMManagedInstanceCoreです。検索欄で「ssm」と入れると探しやすいです。チェックして次へ。タグは特にいらないので次へ。

適当なロール名(今回は「workload-ec2-role」)を入力して「ロールの作成」をします。

IAM RoleができたらEC2を作成します。EC2のマネジメントコンソールで「インスタンスを起動」します。

今回はAmazon Linux 2を選択します。

インスタンスのスペックは必要ないのでt2.microのまま進みます。

Workload VPCのプライベートサブネットを選びつつ、IAM Roleも忘れずに設定します。ストレージは特に変えなくていいのでそのまま次へ進みます。

Nameタグを適当に(今回は「workload-ec2-a」)入力します。

セキュリティグループは既存からworkload-web-sgを指定します。確認画面や鍵の指定などを行い作成を完了します。

作成してしばらくしたらインスタンスを選択して「接続」します。

通信が正常に通っていればセッションマネージャーの「接続」を行えます。

接続したらhttpdのインストールと有効化、index.htmlの設置を行います。以下のような工程で実施します。

sh-4.2$ sudo su - ec2-user
[ec2-user@ip-10-0-110-26 ~]$ sudo yum install -y httpd
…省略…
Complete!
[ec2-user@ip-10-0-110-26 ~]$ echo workload-a | sudo tee /var/www/html/index.html
workload-a
[ec2-user@ip-10-0-110-26 ~]$ cat /var/www/html/index.html
workload-a
[ec2-user@ip-10-0-110-26 ~]$ sudo systemctl enable httpd
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
[ec2-user@ip-10-0-110-26 ~]$ sudo systemctl start httpd
[ec2-user@ip-10-0-110-26 ~]$ sudo systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2021-03-12 22:42:03 UTC; 5s ago
…省略…
[ec2-user@ip-10-0-110-26 ~]$ curl localhost
workload-a

できたら別のAZにもう1台同じようなEC2を作成します。今回こちらのindex.htmlはworkload-cとして違いがわかるようにしました。

VM-Series上でトラフィックが通っているか確認する場合には「MONITOR -> トラフィック」で確認できます。ここにログがなければどこかが間違っていてVM-Seriesへ通っていません。

EC2が準備できたのでALBを作成します。GWLBと同じようにEC2のロードバランサー画面から作成開始します。Application Load Balancerの「作成」を選択します。

適当な名前(今回は「workload-alb」)を入力し、インターネット向け、リスナープロトコルをHTTPのままで下にスクロールします。

VPCとAZを適切に選択して次へ進みます。

セキュリティグループも作成してあるのでALB用のものを選択して次へ進みます。

ターゲットグループの名前を適当に入力し(今回は「workload-tg」)次へ進みます。

下部のインスタンスを選択して「登録済みに追加」して確認へ進め、作成完了します。

しばらくして状態がactiveになったらDNS名を使って実際にブラウザでアクセスしてみます。

うまく行けばindex.htmlが表示され、リロードしていると別のインスタンスに切り替わり適切にロードバランシングできていることが確認できます。

侵入防御

侵入防御を適用していきます。まずは最新の脅威情報を取得しつつ、自動更新の設定を行います。

VM-Seriesの管理画面で「DEVICE -> ダイナミック更新」にアクセスし、下部の「今すぐチェック」を押します。

しばらくするとアンチウイルス / アプリケーション及び脅威の最新の脅威情報ファイルの一覧が取得されます。この状態はまだファイルのリストであり実際にそれが取り込まれていません。

まず自動更新の設定を行います。それぞれの種類毎にスケジュール設定があるのでリンクをクリックして変更していきます。

間隔は自由ですが、今回はアンチウイルスは毎日、アプリケーション及び脅威は毎週にしました。アクションはダウンロードのみと+インストールとがあります。今回はインストールまでやるようにしました。

スケジュールはすぐに実行されないので今回は手動でダウンロードとインストールします。アンチウイルス / アプリケーション及び脅威それぞれリストの中から一番新しい日付のものを「ダウンロード」します。ダウンロードが完了するとアクション欄に「インストール」のリンクが表示されるのでそちらも押してインストールまで完了します。